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ABSTRACT 


The Styx (9p) protocol has been well documented for use in various dis- 
tributed systems [1, 2]. Demonstrations have proven that it works for 
communication with embedded devices [3, 4, 7]. This paper presents an 
implementation of 9p for the 16-bit dsPIC33 family of digital signal con- 
trollers. It is used to collaborate multiple distributed nodes to achieve 
stable aero-acoustic levitation of a sample by tuning sound pressure lev- 
els and managing spin control. 


1. Introduction 


Aero-acoustic levitation (AAL) has been achieved in the past using analog systems with 
purely manual controls [8, 9]. A newly designed AAL instrument is being built based 
around a cluster of digital control boards. Each board includes a dsPIC33 embedded 
controller and an FPGA to handle manual inputs paired with position feedback control 
sensors used to drive a transducer and produce a stable acoustic field during experi- 
ments where significant changes in temperature will be applied to a sample. Tempera- 
ture changes modify the speed of sound and thus sound pressure levels at the desired 
focal point. The distributed system of transducer control boards is used to calibrate and 
adjust acoustic phase and amplitude along three axes to levitate and hold a sample ina 
fixed position during solid to liquid-phase processing studies. 


In addition to a manual control interface, this new system implements a fully digital con- 
trolled interface available on an end user’s terminal. This newly designed system uses 
9p for tuning core parameters on each node as well as communication with external ter- 
minals. Exporting all the node sensor data to a single namespace on a user’s terminal 
provides for clean logging and real-time analysis of state changes during an experi- 
ment. 


1.1. Aero-acoustic Levitation 


Research into containerless liquid-phase processing of materials led to the invention of 
aero-acoustic levitators [8]. The combination of gas jet (aero) and acoustic forces help 
to stabilize the sample in a levitated (containerless) field such that rapid heating and 
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cooling techniques can be applied. In this example it is principally used to conduct 
experiments on samples that may be super heated to temperatures above 2700°K and 
rapidly cooled without requiring a crucible or other physical container. Such experi- 
ments test the viscosity and surface tension of a sample within a controlled environment 
able accommodate key state changes important for theoretical and applied material sci- 
ence studies. 


1.2. Controller Boards 


A distributed feedback control system is used in order to achieve aero-acoustic levita- 
tion of samples during significant fluctuations in temperature. A gas jet counteracts 
gravitational force and is controlled by the user or a program interfacing with an elec- 
tronically controlled flow valve. Three acoustic axes, a pair of transducers each, are 
used to provide levitation, stabilization, and spin control of a sample. Position detectors 
are used perpendicular to each acoustic axis, three in total, to aid in stabilization and to 
coordinate placement of a sample positioned at the intersection point of the gas flow 
and the two lasers used in melting the sample. Each component is wired to one of eight 
controller boards sharing a system bus with software running on the dsPIC33. 


By tuning the acoustic phase of each axes to focus a standing wave above the gas jet 
and near the ideal point for heating a sample, the deadline in which any system event 
needs to respond becomes quite long. This leaves more than enough time for handling 
9p messages at relatively regular intervals. By implementing 9p on the dsPIC33 embed- 
ded controller there ends up being enough memory and free cycles to handle feedback 
loop calculations without requiring further development like the Styx /P—Core on an 
FPGA [7]; however, the option is still there for future research. 


2. The River Styx 


Each of the eight nodes in the AAL cluster resides in a single chassis with three commu- 
nication channels: one exposed through a RS-232 interface, and two through the back- 
plane. The first dsPIC33 code used a simple protocol requiring the use of a dumb termi- 
nal connected to each board over the RS-232 interface. This configuration allowed for 
single board initialization and verification, but made debugging inter-node communica- 
tion over the 485 and SPI busses all the more difficult. 


After reviewing file system interfaces for mobile resources [1, 5, 6], the case was made 
to implement 9p not just for the serial communication from the host terminal to each 
control node, but as the principal means of communication along the backplane con- 
necting all the nodes in the cluster. This conceptual switch to responding through the 
same protocol over each serial interface made the design and debugging of the system 
all the more practical. A master node constructs a representation of the rest of the clus- 
ter and exports its namespace using 9p over its RS-232 port. All other nodes are dedi- 
cated to reporting the state of their various sensors and calculating responses based on 
their dedicated feedback loops. 


2.1. Embedded Server 


Each node with a dsPIC33 serves a single-level namespace with two files: ctl, and status. 
As with devices on Plan 9 and Inferno (e.g., uart(3)) the ctl file is used to write configu- 
ration parameters to the board. The status file returns the measured state of all the 
sensors accessible to the embedded controller: output voltage, output current, phase, 


mic amplitude, mic phase, temperature, etc. 


Future implementations could expand the board to provide register and memory details 
of the PIC, allowing for even greater debugging options as well as dynamic updates 
beyond the simple scope of variables required for achieving levitation. 


2.2. Embedded Client 


A single master board is used as a gateway between all the controller nodes and a user’s 
computer terminal. After board initialization, the master node scans the backplane for 
all other connected boards, and uses 9p to set up a multilevel namespace representing 
the system. All the non-master nodes are hot pluggable, so the master node’s exported 
representation of the system will change as a node is disconnected or inserted. In turn, 
the master board exports a namespace over its RS-232 serial interface, providing a syn- 
thesized file system to the user’s application with a synopsis: 


mount /dev/eiaO /n/aal 


/n/aal/ctl 
/n/aal/status 
/n/aal/transtatus 
/n/aal/[0-6]/ct1l 
/n/aal/[0-6]/status 


The transtatus file contains the last polled state of all the transducer controller nodes, 
numbered 0-5, eliminating the need to re-poll each node in order to respond to the 
application’s request. 


3. Experimental Control Application 


The whole exercise of getting 9p on all of these embedded controllers is to provide a 
consistent API for firmware development and expose a relatively simple interface for end 
user application programmers to design and support experimental controls over various 
sample materials in order to have precise position and spin control. There are multiple 
built-in feedback loops that adjust the system’s parameters in real-time when enabled, 
though there is programmatic control over these events as well. All changes get 
reported back over timed reads by the master node (host application) of all other status 
files. Doing so allows for an experimenter/programmer to create events that can be 
programmed through scripts and run once the sample is levitated. A typical startup 
example is: 

# create namespace 

bind -a ’#t’ /dev 

mount -bc /dev/eia0 /n/aal 

linkflowmeter /dev/eial 

mount -a /net/flowmeter /n/aal 

linkheatsource /dev/eia2 

mount -a /net/heatsource /n/aal 


echo off > /n/aal/heatctl 
echo off > /n/aal/flowctl 


# acoustic calibration routines 
echo findq > /n/aal/ctl 

echo pick > /n/aal/ctl 

echo phase > /n/aal/ctl 


# prep for sample insertion 
echo A .2 > /n/aal/ctl 
echo 1000 > /n/aal/flowctl 


# change phase on one axis 

echo p+1 > /n/aal/[01]/ctl 

# increase amplitude from top transducers 
echo a+1 > /n/aal/[1,3,5]/cetl 


# pseudo code to decrease amplitude over 30s 
for(i in ‘{seq -1 O})f{ 

echo a-1 > /n/aal/ctl 

sleep 1 


4. Conclusion 


The use of 9p for inter-process communication in a distributed cluster provided a valu- 
able interface for reading and writing sensor data on a dsPIC33 within certain deadline 
constraints on each of the eight nodes in the cluster. It also allowed for application 
development to use a simple file hierarchy to monitor and control a running system. Ini- 
tial shell script prototypes were used on Plan 9 or Inferno depending on the developer’s 
host system. Subsequent applications were written in Limbo and provided as reference 
implementations for the use of 9p over the RS-232 interface. 
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